A problem can occur compiling programs that use MPW 3.2 Pascal along with the DTS UFailure, Signals, or GetZoneList samples, or the code given in Technical Note #81, Signals. If your program is based on one of these samples, the following information applies to you.
The problem is that a new optimization made by the Pascal compiler conflicts with an assumption made by UFailure (and friends). Normally, the Pascal compiler generates a "static link" to allow a nested procedure to reference variables defined by the procedure in which it is nested. The MPW 3.2 version of Pascal contains an optimization to notice that a nested procedure doesn't reference any variables in the outer scope, in which case it determines that the static link is unnecessary, and omits it.
Unfortunately, the UFailure mechanism assumes the presence of this static link in passing an error return value to the nested procedure. Without the static link, the UFailure mechanism places the error in the wrong place on the stack, and when the nested procedure (the error handler) is called, the error value incorrectly appears to be zero, "no error".
When can this happen? If the outside procedure's parameter is declared as a ProcPtr, the problem occurs, because the mechanism used to call the nested procedure would have to take the static link into account, but cannot know whether the static link has been optimized away:
PROCEDURE BadExample(yourProcedure: ProcPtr);
There's no problem if it really is a procedure parameter:
PROCEDURE GoodExample(PROCEDURE YourProcedure;);
If your application is written using the former interface, you can avoid the problem by turning off the new optimization, using the "-opt nostatic" option of the Pascal compiler.
